為什麼我要寫這個系列

這幾年，無論是企業內部的數位轉型專案，還是各種新創產品的架構設計，「微服務」這三個字幾乎成了必談的關鍵字，我自己也因為這樣接到很多案子的資訊。許多 RFP（需求建議書）裡面直接要求系統必須符合微服務架構；開發團隊在設計新系統時，也會自然地把「要不要切成微服務」放進最初的架構考量。

然而，我在實務中常常遇到兩種極端的情況：

• 過度理想化：很多人把微服務當成「萬靈丹」，認為導入之後一切問題都能解決。但，對於自己真的遇到的問題並沒有進一步地分析。(通常是業主)
• 過度抗拒：也有人認為微服務是「巨大負擔」，只會帶來複雜度與額外成本。(通常是承接專案的執行團隊)

這兩種看法都有偏頗。微服務不是靈丹妙藥，但它也不是洪水猛獸。它是一種架構模式（Architecture Pattern），是眾多解決方案中的一種。它適合某些場景，但也可能完全不適合另外一些場景。

因此，我想整理一下自己日常的筆記，撰寫「微服務導入 30 講」系列文章，希望透過循序漸進的分享，從我自己理解的角度，讓大家從基礎認識、設計模式、資料治理、測試部署到真實挑戰，都有一個完整的理解。(或許有些概念不完全正確，就再等大神來互相指教了)。

微服務到底是什麼？

所謂微服務，其實並沒有一個完全一致的定義。一般來說，我們可以把它理解成：

一種將應用程式設計為一組小型、自治、鬆耦合服務的架構風格，每個服務對應到一個獨立的業務能力，並且透過清晰的 API 來彼此協作。

我自己更常講的是節錄自 Martin Fowler 文章的一段話：

微服務是圍繞業務領域塑模而成，可獨立發布的服務。

在我接觸微服務比較早期，通常大家會問的一個問題是切多小是一個微服務？我是一個從「服務導向架構，Service Oriented Architecture」年代一直走下來的一位軟體從業人員。

早期，拜讀 IBM SOMA 的方法論來協助企業做「服務設計」，在其中一個重要的討論議題就是「服務顆粒度」。但是，在微服務的知識領域中我體悟到的是「大小」可能不是我們需要關注的重點。簡單說：

• 「小」是相對的，不是真的越小越好，而是「適當切分」。
• 「自治」代表每個服務應該能獨立部署、獨立演進，不需要依賴其他服務的生命週期。
• 「鬆散耦合」代表服務之間應該透過協定明確的介面來溝通，而不是直接共享資料或程式碼。

這樣的設計帶來一個核心價值：能讓系統隨著業務演進而更有彈性，避免單體架構（Monolith）那種「牽一髮動全身」的困境。（至於是不是真的，就是在各個實踐者心中的甘苦談了）。

為什麼要導入微服務？

通常我都是從接到一個專案開始，而這個專案就說他要用微服務的架構，所以故事就開始了！

不過，這可能不是一個強而有力支撐我們去導入微服務的理由，所以我從一些書籍上看一下導入微服務架構的場景，大多數是要做下列幾項：

系統的可擴展性

當系統越來越大，我們往往會遇到某些模組負載特別高，導致整體瓶頸。如果是單體架構，我們只能「整個應用程式一起擴展」；而微服務允許我們只擴展需要的部分。

團隊的自主性與開發的速度

如果一個系統全部塞在同一包程式裡，十幾個甚至幾十個團隊一起改，最後誰也動不了(我現在就在一個有這種規模的專案中)。微服務讓團隊對應業務邊界（Bounded Context），能獨立決策與部署，大幅加快開發速度(我們試圖透過專業分工讓事情變得更有秩序更加順利)。

技術選型的自由度

微服務允許不同服務用不同的技術棧，能逐步引入新技術，而不是被舊技術綁死。這對於長期演進的系統來說至關重要。(基本上，只要遵循以 API 來實現模組與模組之間的溝通，這可能就已經不是難事)。

當然，微服務的代價也很真實：分散式系統的複雜度、資料一致性的挑戰、維運成本的增加。這些我們會在後續章節逐步拆解。

讀完這個系列，你會有什麼收穫

我的目標是讓這個系列成為 架構師、開發者、甚至 PM 都能理解的知識框架。當你看完 30 篇文章之後，你應該會有以下幾個收穫：

• 系統觀點：你能分辨哪些情況適合微服務、哪些情況不適合。 (勇敢說不也是一種專業)
• 設計能力：你能使用 DDD 的語言（Bounded Context、Aggregate、Domain Event）來拆分服務。
• 資料治理概念：你會理解「Database per Service」不是口號，但有很多設計的細節需要考量。
• 技術能力：你會知道 API Gateway、Service Mesh、Kubernetes、CI/CD 如何支撐整個生態。
• 可觀測性與測試：你會學會怎麼建立分散式追蹤、日誌聚合、合約測試，確保微服務真正能維運。
• 真實挑戰與反思：你不會只看到好處，還能理解為什麼有些團隊導入失敗，甚至會選擇「不做微服務」。

換句話說，這個系列不是要「推銷微服務」，而是要幫助你做出更好的判斷，在該用的地方用，該避免的地方避開。

結語

微服務不是終點，它只是一種手段。更重要的，是我們是否真正理解了背後的設計原則，以及它對組織、技術、團隊的深遠影響。

這就是我希望透過這個系列，和大家一起思考與討論的起點。